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Abstract 

U.S.  Federal  agencies  face  the  challenge  of  conducting  a  dynamic  analysis  of  their 
architectures  to  determine  the  performance  and  effectiveness  of  the  business  processes 
and  the  supporting  Information  Technology  (IT)  systems.  Most  architectures  are  static 
representations  and  lack  the  capability  to  support  the  dynamic  analysis  required  to 
generate  the  performance  and  effectiveness  metrics.  There  is  an  added  challenge  for 
organizations  that  must  interoperate  with  other  Federal  agencies.  Failing  to  integrate  with 
other  agency  architectures  may  create  critical  interoperability  problems  resulting  in 
mission  failure.  The  challenge  is  not  only  to  ensure  satisfactory  interoperability,  but  also 
to  determine  that  the  mission  will  in  fact  be  accomplished  and  that  critical  gaps  do  not 
exist  among  the  architectures.  This  paper  discusses  a  case  study  that  addressed  these 
challenges  by  examining  an  operation  where  architectures  from  multiple  agencies,  using 
different  frameworks,  were  integrated  to  accomplish  a  coastal  security  mission.  The 
paper  describes  the  technical  approach  involving  two  phases.  The  Static  Phase  developed 
a  Multi-agency  Operations-Centric  Architecture  Activity  Model  consisting  of  the 
mission,  supporting  operations,  and  mission-essential  tasks.  The  Dynamic  Phase  took  this 
activity  model  and  imported  it  into  a  set  of  simulation  tools.  The  paper  also  identifies 
insights  about  applying  multi-agency  architectures. 
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Introduction 


The  Clinger-Cohen  Act,  and  Office  of  Management  and  Budget  Federal  Enterprise 
Architecture  (OMB-FEA)  guidelines  dictate  the  development  and  use  of  Enterprise 
Architectures  in  the  Capital  Planning  and  Investment  Control  (CPIC)  process  for 
acquiring  information  systems.  [1][2]  Enterprise  Architectures  represent  perhaps  the  most 
complete  set  of  information  on  the  structure  of  an  agency  enterprise;  however  they  are 
static  point  representations.  Emerging  capabilities  for  mission  and  business  performance 
simulations  enable  the  coupling  of  static  architecture  elements  to  a  dynamic  simulation 
environment  -  the  executable  architecture. 

Under  current  guidelines,  Federal  agencies  must  develop  and  document  information 
technology  (IT)  architectures  by  using  a  framework  to  guide  the  descriptions  of  these 
architectures.  A  framework  provides  the  rules,  guidance,  and  basis  for  developing  and 
presenting  architecture  descriptions  in  a  uniform  and  consistent  manner  and  is  intended  to 
ensure  that  the  architecture  descriptions  can  be  understood,  compared  and  related  across 
organizational  boundaries.  To  accomplish  this,  a  framework  defines  numerous  products 
to  capture  specific  architectural  views.  Architecture  products  are  those  graphical,  textual, 
and  tabular  items  that  are  developed  in  the  course  of  building  a  given  architecture 
description  that  describe  characteristics  pertinent  to  the  architecture’s  purpose.  A 
framework  by  definition  is  very  flexible,  which  is  valuable  in  allowing  each  organization 
to  document  architectures  in  a  way  that  is  best-suited  for  the  individual  organization. 
However,  because  of  this  flexibility,  there  are  not  only  multiple  frameworks  that  meet  the 
requirements,  but  also  multiple  tools  to  implement  each  framework. 

A  majority  of  the  framework  products  currently  being  produced  provide  “static” 
representations  of  information  for  their  various  views.  While  these  static  products  capture 
enormous  amounts  of  information  about  the  Operational  Architecture  (OA)  components 
(business  processes,  activities,  information  flow,  and  organizational  structure),  and  the 
System  Architecture  (SA)  components,  they  fail  to  provide  a  good  vehicle  for  conducting 
detailed  dynamic  “behavior”  analysis  of  how  the  components  are  supposed  to  interact 
with  each  other. 

This  paper  discusses  the  methodology  and  challenges  in  applying  architectures  of 
multiple  agencies  to  support  a  common  mission.  The  methodology  uses  executable 
architectures  to  conduct  a  dynamic  analysis  of  operations  performed  by  the  agencies 
assigned  to  the  mission.  The  approach  to  the  analysis  was  in  the  form  of  a  case  study  that 
involved  a  homeland  security  mission. 

Objective 

The  objective  of  this  case  study  is  to  examine  the  technical  challenges  and  issues 
associated  with  interoperability  and  information  sharing  when  multiple  agencies, 
represented  by  different  architectures  built  with  different  architecture  frameworks,  must 
function  together  to  accomplish  a  mission.  To  address  issues  associated  with  multi¬ 
agency  operations,  we  use  a  case  study  involving  activities  drawn  from  the  Universal 
Task  Lists  of  participating  agencies  executing  a  large  coastal  security  operation.  These 
mission-critical  operational  activities  provide  content  for  the  Enterprise  Architectures 
of  participating  agencies. 


Note:  Due  to  sensitivities  in  the  scenario,  specific  details  of  the  case  study  will  not  be 
discussed  here. 


Technical  Approach 

The  technical  approach  divided  the  case  study  into  two  main  phases,  a  Static  Phase  and  a 
Dynamic  Phase.  The  Static  Phase  addressed  the  assembly  of  the  multi-agency 
architecture  products  needed  to  describe  the  organizations  and  information  flows  for  a 
selected  scenario.  The  Dynamic  Phase  addressed  the  approach  to  examine  the 
performance  and  effectiveness  of  the  multi-agency  architecture  in  the  operational 
environment  described  by  the  scenario. 

The  technical  approach  applied  many  of  the  insights  and  lessons  learned  from  two 
previous  MITRE  research  projects,  the  Multi-agency  Enterprise  Architecture  Planning 
Framework  MITRE  Sponsored  Research  (MSR)  and  the  Executable  Architecture 
Methodology  for  Analysis  (EAMA)  Mission  Oriented  Investigation  and  Experimentation 
(MOIE). 

The  MSR  provided  the  multi-agency  framework  for  much  of  the  Static  Phase  of  the  case 
study.  This  previous  research  helped  define  the  concept  of  a  Multi-Agency  Operations- 
Centric  Architecture,  an  architecture  that  is  focused  on  conducting  operations  associated 
with  a  specific  mission  or  an  Operations  Plan  (OPLAN).  [3]  This  approach  is  in  contrast 
to  a  Unit-Centric  Architecture  that  focuses  on  an  organization’s  structure  and  how  it 
accomplishes  numerous  activities  related  to  multiple  missions.  The  concept  of  the  Multi- 
Agency  Operations-Centric  Architecture  and  its  relation  with  individual  agency 
architectures  is  illustrated  in  Figure  1.  The  Operations-Centric  Architecture  provides  the 
mission  and  the  top-level  construct  under  which  the  individual  agency  architectures  are 
mapped  with  the  details  of  the  activities,  services,  data  and  technology. 


Multi-Aaencv 

Operations-Centric  Architecture 


Figure  1.  Relationship  of  Architectures 


The  MSR  also  provided  a  Readiness  Model  that  describes  five  levels  of  interaction 
among  agencies  and  organizations  when  they  are  tasked  to  support  a  mission.  The  levels 
of  interactions  in  the  Readiness  Model  range  from  Mission  Independence  where  there  is 
no  common  mission  to  Mission  Integration  where  the  missions  are  so  closely  intertwined 
that  the  different  agencies  should  be  structured  into  one  organization.  [4]  Finally,  the 
MSR  also  provided  a  web-services  tool  to  help  develop  the  Multi-Agency  Operations- 
Centric  Architecture  by  allowing  users  to  pull  together  the  pieces  of  the  various  agencies’ 
architectures.  [5] 

The  EAMA  MOIE  supported  the  Dynamic  Phase  of  the  case  study  by  providing  the 
methodology  to  generate  executable  architectures  that  could  support  the  dynamic  analysis 
of  the  Operations-Centric  Architecture.  The  research  in  the  MOIE  focused  on  a  single 
agency’s  architecture  and  how  to  address  that  agency’s  performance  and  effectiveness 
using  executable  architectures.  The  case  study  attempts  to  extend  that  capability  by 
expanding  the  scope  to  an  architecture  involving  multiple  agencies.  The  MOIE  provided 
the  guidelines  and  rules  to  allow  the  conversion  of  the  static  Operations-Centric 
Architecture  into  an  executable  form  in  a  set  of  simulation  tools.  [6] 

Static  Phase 

The  Static  Phase  of  the  case  study  used  an  Activity-based  approach  to  develop  the  Multi- 
Agency  Operations-Centric  Architecture.  Using  the  top-level  mission  statement,  we 
created  a  generic  Activity  Model  that  captured  the  main  set  of  activities  for  the  general 
case  of  the  selected  scenario.  We  used  three  levels  to  develop  the  Activity  Model.  This 
follows  a  common  structure  used  by  organizations  such  as  the  Department  of  Homeland 
Security  in  its  recent  Universal  Task  List  (UTL)  document.  [7]  The  Department  of 
Defense  also  uses  this  structure  in  its  Universal  Joint  Task  List  (UJTL).  [8] 

The  top  level  activity  is  the  mission  to  be  accomplished.  The  mission  is  then  decomposed 
into  activities  that  represent  the  main  operations  that  must  be  performed  to  accomplish 
the  mission.  We  assign  one  or  more  agencies  to  perform  each  operation.  We  decompose 
each  operation  into  mission  essential  tasks  (MET)  that  are  defined  for  the  organizations 
assigned  to  each  Operation.  Typically,  the  MET  are  found  within  the  UTL  or  UJTL  with 
additional  detail  in  the  Operational  Activity  Model  of  the  organization’s  architecture, 
which  decomposes  these  tasks  even  further.  These  tasks  describe  the  key  activities  that 
the  organization  must  perform  to  accomplish  its  assigned  missions.  When  the  second- 
level  Operations  were  mapped  to  the  appropriate  Mission  Essential  Tasks  for  the  assigned 
agency,  we  inserted  the  appropriate  portion  of  the  agency’s  Activity  Model  and  built  the 
Operations-Centric  Activity  Model  for  the  scenario.  Figure  2  shows  the  construct  of  an 
Operations-Centric  Activity  Model. 
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Figure  2.  Operations-Centric  Activity  Model 

The  next  part  of  the  Static  Phase  was  to  conduct  a  Gap  Analysis  to  identify  which  parts  of 
the  Architecture  were  missing.  This  occurred  when  we  were  unable  to  find  an  individual 
agency’s  architecture  to  execute  an  activity  in  our  generic  Activity  Model.  There  were  a 
number  of  possible  reasons  for  gaps  in  the  model.  First,  the  agency  identified  to  perform 
the  activity  might  not  have  the  activity  included  as  part  of  its  current  architecture  even 
though  it  should  have.  Second,  there  may  not  be  any  agencies  identified  in  the  original 
organizational  structure  to  accomplish  this  activity.  Third,  there  may  be  no  agencies  that 
had  this  activity  identified  as  part  of  their  mission.  To  resolve  any  gaps,  the  headquarters 
in  charge  of  the  overall  mission  must  identify  if  any  agency  that  is  currently  part  of  the 
mission  can  fill  the  gap  and  if  the  agency  has  the  available  resources  to  perform  the 
activity.  If  this  is  not  possible,  the  headquarters  must  determine  if  a  new  agency  is 
required  to  perform  the  activity.  Any  changes  should  be  reflected  in  an  updated 
Operations-Centric  Architecture.  Obviously,  these  gaps  must  be  filled  while  still  in  the 
planning  phase  of  the  operation. 

After  the  Gap  Analysis  was  completed,  we  conducted  an  Overlap  Analysis.  This  analysis 
identified  the  cases  where  more  than  one  agency  is  identified  to  perform  an  activity.  The 
analysis  should  address  several  issues  including,  if  it  is  necessary  for  these  agencies  to 
perform  the  same  activity.  It  may  be  a  matter  of  insufficient  resources  in  one  agency  and 
thus,  one  or  more  additional  agencies  are  needed  to  supplement  the  primary.  Another 
issue  to  address  is  whether  these  agencies  are  using  different  procedures  to  perform  the 
activity.  If  they  are,  some  investigation  is  needed  to  determine  if  these  differences  might 
create  problems  in  the  execution  of  the  mission,  perhaps  by  confusing  other  participating 
agencies  who  are  expecting  one  procedure  when  a  different  procedure  is  actually  used. 

After  the  Architecture  is  completed  and  vetted,  we  can  move  on  to  the  Dynamic  Phase  of 
the  case  study. 


Dynamic  Phase 


The  Dynamic  Phase  consists  of  several  modeling  efforts  to  put  the  key  components  of  the 
Operations-Centric  Architecture  into  an  executable  form,  i.e.,  in  a  simulation 
environment. 

The  first  effort  is  to  model  the  scenario  in  an  operational  environment  simulation,  or 
scenario  driver.  In  a  military  environment,  this  would  be  a  combat  simulation.  The 
underlying  concept  is  to  represent  all  the  key  entities  (units,  agencies,  people,  sensors, 
weapons  systems,  vehicles,  aircraft,  and  vessels)  in  their  appropriate  terrain  and 
environment  (air,  land,  sea,  weather  conditions,  etc.)  to  show  how  events  and  interactions 
among  these  entities  would  occur.  To  model  this  correctly,  maps,  entity  icons,  movement 
routes,  and  actions  must  be  developed  in  the  scenario  driver.  We  used  a  tool  called  Joint 
Military  Art  Command  Environment  (JMACE)  as  the  scenario  driver.  [9] 

The  second  modeling  effort  is  to  import  the  key  business  processes  from  the  Architecture 
into  a  process  modeling  tool.  One  option  is  to  import  all  business  processes  into  one  tool. 
Another  option  is  to  divide  up  the  business  processes  among  different  tools  so  that  the 
processes  of  one  type  agency  (e.g.,  DoD)  are  in  one  tool  and  the  processes  of  another 
type  agency  (e.g.,  DHS)  are  in  another  tool.  This  provides  some  flexibility  as  well  as 
providing  the  realization  that  different  agencies  will  likely  use  different  tools  to  model 
their  architectures.  We  used  a  tool  called  Bonapart  as  the  process  modeling  tool.  [10] 

The  third  effort  is  to  model  the  communications  networks  in  a  network  modeling  tool. 
The  network  model  allows  the  calculation  of  any  delay  times  in  passing  data  due  to  the 
load  on  the  communications  network  and  the  capability  of  the  systems  to  send  and 
receive  data  in  the  proper  format  with  the  appropriate  communications  means.  We  used 
NetSim  (NS-2)  as  the  communications  network  modeling  tool.  [11] 

After  capturing  the  architectures  in  these  simulations,  we  linked  the  simulations  into  a 
High  Level  Architecture  (HLA)  federation.  The  HLA  federation  manages  the  sharing  of 
object  attributes  across  the  simulations  and  synchronizes  the  time  among  the  simulations 
so  that  they  stay  at  the  same  simulation  time  until  all  simulations  are  ready  to 
advance.  [12] 

Conducting  the  Analysis 

After  running  the  simulations,  we  conducted  an  analysis  of  the  simulation  runs  to 
determine  the  performance  and  effectiveness  of  the  architecture.  The  analysis  consisted 
primarily  of  examining  output  from  JMACE  and  Bonapart  to  determine  the  measures  of 
force  effectiveness  (MOFEs),  the  measures  of  effectiveness  (MOEs)  and  measures  of 
performance  (MOPs)  from  the  simulation  run.  Our  MOFEs  from  JMACE  included  how 
well  the  agencies  accomplished  their  assigned  missions.  The  MOEs  in  Bonapart  included 
the  overall  process  time  for  each  business  process.  The  MOPs  in  Bonapart  included  the 
time  required  to  conduct  an  activity  in  a  business  process  and  the  utilization  of  resources 
(human  and  system).  The  MOPs  in  NS-2  included  the  delay  time  between  nodes. 


By  determining  these  measures,  we  can  determine  if  the  business  processes  are  occurring 
in  a  timely  manner,  and  if  the  agencies  executing  the  mission  are  achieving  the  desired 
objectives.  Additionally,  with  a  full  scale  representation  of  the  OPLAN,  including  all 
resources  and  activities,  we  could  examine  other  organizational  issues  such  as  the  over- 
or  under-utilization  of  critical  resources.  For  example,  we  may  have  discovered  through 
the  analysis  that  when  the  operation  reached  a  certain  level  of  intensity,  the  resources  of 
one  of  the  agencies  had  reached  its  limits.  At  this  point,  the  agency  would  need  the 
support  of  the  other  agencies  that  can  perform  the  same  operation.  Further  analysis  of  the 
scenario  may  also  indicate  that  changes  are  needed  in  the  organizational  structure  or  the 
assignment  of  operations.  This  is  representative  of  the  type  of  analysis  that  can  be 
accomplished  with  this  capability. 

Insights  and  Lessons  Learned 

The  research  challenges  encountered  along  the  way,  while  limiting  the  scope  of  the  study, 
provided  a  number  of  valuable  insights  and  lessons  learned  from  the  effort.  The  primary 
challenges  were  the  limitations  in  the  architecture  products  that  were  available  and  the 
shortcomings  of  the  simulation  tools  that  were  available  for  the  scenario  we  used. 

There  are  several  insights  lessons  learned  gained  through  this  case  study  that  apply  to 
both  the  architecture  and  the  planning  communities  within  agencies. 

Lack  of  Architecture  Maturity,  Consistency  and  Content 

There  are  critical  shortcomings  in  organizations’  architectures  that  prevent  them  from 
easily  integrating  with  other  organizations’  architectures  to  create  a  mission  operations- 
centric  architecture. 

This  is  understandable  as  the  architectures  are  generally  constructed  for  the  more  limited 
purpose  of  Capital  Planning  and  Investment  Control  (CPIC).  Although  the  work 
performed  in  this  research  is  directed  at  adding  capabilities  for  a  more  robust  application 
of  architectures  to  operations  planning  and  analysis,  these  added  capabilities  will  also 
make  for  more  effective  performance-based  CPIC  applications. 

Having  gone  through  a  practical  exercise  of  trying  to  assemble  the  right  pieces  of 
architectures  from  organizations  to  analyze  the  operational  performance  of  mission 
organizations  and  supporting  information  services,  several  things  are  clear.  First,  these 
architectures  generally  lack  a  level  of  maturity  and  consistency  to  allow  them  to  be 
integrated  as  part  of  a  larger  architecture. 

Second,  these  architectures  lack  a  reasonable  level  of  mission,  business,  and  technical 
detail  to  allow  the  type  of  modeling  and  simulation  required  to  execute  a  scenario 
involving  multiple  agencies.  The  level  of  detail  of  the  operational  activities  and 
information  being  passed  between  activities  is  insufficient  to  model  the  actions  required 


by  the  OPLAN.  Significant  additional  modeling  is  required  to  support  the  proper 
representation  in  the  simulations. 

Third,  most  of  the  architectures  lack  the  complete  set  of  activities  related  to  the  scenario 
we  examined  in  the  case  study.  Even  when  related  activities  could  be  identified,  they 
lacked  the  fidelity  of  definition  required  to  identify  the  resources  employed.  Although  a 
particular  agency  was  supposed  to  be  performing  certain  activities  in  the  operation,  those 
activities  did  not  appear  in  the  agency’s  architecture  or,  the  description  of  an  activity  was 
too  general  to  really  apply  it  to  the  model. 

One  area  that  has  not  been  addressed  between  the  architecture  community  and  the 
operational  community  is  how  architectures  support  required  operational  documentation 
such  as  an  Operations  Order  (OPORD)  or  an  Operations  Plan  (OPLAN).  As  the 
architecture  domain  matures  and  we  gain  a  greater  understanding  of  how  to  apply 
architectures,  there  must  be  a  merger  of  terminology  and  structure  captured  in 
architectures  with  the  scenario  specific  information  of  an  OPORD  or  OPLAN. 
Operational  Activities,  Operational  Nodes,  Information  Exchanges,  and  Event  Traces 
from  architectures  must  help  organizations  flesh  out  their  OPLANs  and  OPORDs.  This  is 
the  basic  concept  of  an  Operations-Centric  Architecture. 

Additionally,  well-developed  architectures  can  assist  in  identifying  what  needs  to  be 
changed  in  terms  of  organization,  processes  and  capabilities.  In  DoD,  this  is  typically 
described  in  terms  of  solutions  in  the  areas  of  Doctrine,  Training,  Leadership 
Development,  Organization,  Materiel,  Personnel,  and  Facilities  (DTLOM-PF).  By 
examining  various  parts  of  an  architecture,  potential  solutions  in  one  of  the  DTLOM-PF 
areas  may  emerge.  For  example,  we  can  determine  if  Doctrine  needs  some  changes  by 
examining  the  Operational  Nodes,  the  Operational  Activities  performed  at  those  nodes, 
the  Human  Roles  performing  the  activities,  and  the  Information  passed  among  the 
activities.  An  examination  of  these  components  provides  insights  into  problems  with  the 
processes  employed,  utilization  of  resources,  and  Tactics,  Techniques  and  Procedures 
(TTP)  for  the  organization.  Another  example  is  to  examine  the  linkage  between  the 
Human  Roles  and  the  Systems  those  humans  are  using  to  address  the  requirements  and 
possible  shortcomings  in  Training. 

Architecture  Interoperability 

Multi-agency  modernization  environment  adds  significant  complexities  for  which  current 
architectures  are  inadequate.  Architectures  are  currently  being  developed  in  an  isolated 
environment,  i.e.,  there  is  no  clear  attempt  to  proactively  develop  the  architectures  to 
support  integrating  them  with  other  architectures  to  represent  a  multi-agency,  operations- 
centric  architecture.  The  complexity  of  a  multi-agency  environment  is  not  being  captured 
in  the  individual  architectures  that  must  comprise  the  multi-agency  architecture  for  that 
environment.  This  hampers  attempts  to  integrate  these  architectures  and  to  conduct  any 
significant  analysis  of  their  capability,  performance,  and  effectiveness  in  accomplishing 
the  mission. 


Architectures  must  be  developed  with  the  understanding  that  they  must  interoperate  with 
many  other  architectures.  Terminology,  naming  conventions,  and  notation  standards  for 
architectures  must  be  established  to  ensure  compatibility  when  integrating  architectures 
from  different  sources.  Just  as  notation  standards  have  been  established  for  building 
architecture  blueprints,  similar  standards  are  needed  for  IT  architecture  documentation 
that  will  facilitate  a  common  understanding  of  architectures  developed  in  different 
frameworks  or  by  different  architects. 

Approach  to  Performance  Analysis 

The  EAMA  approach  offers  a  potential  methodology  to  conduct  performance  analysis  as 
addressed  by  the  OMB-FEA  Performance  Reference  Model  (PRM).  [13]  We 
demonstrated  an  approach  to  performance  analysis  that  implements  essential  features  of 
the  PRM.  The  PRM  outlines  a  general  approach  to  measuring  and  assessing  performance, 
but  it  also  recommends  that  this  approach  be  ‘operationalized’  for  the  specific 
environment  of  the  agencies  involved.  This  research  operationalizes  the  performance 
aspects  of  the  multiple  agencies  involved  in  one  scenario  for  the  homeland  security 
domain.  The  application  of  executable  architectures  to  multi-agency  operations  allows  us 
to  address  the  gaps  and  overlaps  among  the  architectures  being  integrated  to  support  the 
multi-agency  mission.  By  identifying  the  gaps,  we  can  determine  any  shortcomings  of  the 
agencies  tasked  to  accomplish  a  common  mission.  By  identifying  the  overlaps,  we  can 
determine  potential  opportunities  where  duplicate  effort  may  occur,  or  where  differences 
in  processes  by  agencies  performing  similar  tasks  may  cause  operational  problems  in 
execution.  Performance  analysis  must  include  a  capability  to  conduct  a  dynamic  analysis 
of  the  architecture  in  question.  Executable  architectures  provide  a  logical  approach  to 
dynamic  analysis. 

Conclusion 

The  major  conclusion  is  that  the  Multi-Agency  Executable  Architecture  approach, 
coupling  a  Multi-Agency  Operations-Centric  Architecture  with  dynamic  simulation,  can 
provide  a  robust  framework  for  complex  multi-agency  modernization  and  operations 
planning.  By  adding  a  dynamic  analysis  capability  to  the  toolkit,  architects  can  examine 
and  assess  their  architectures  to  determine  if  they  adequately  support  a  multi-agency 
mission.  Likewise,  those  in  the  operational  world  can  use  executable  architectures  to 
examine  and  assess  their  OPLANS  to  determine  if  they  have  any  critical  shortcomings. 
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Project  Objectives 


•  Examine  multi-agency  architecture  issues  thru  a  case  study 
where  multiple  agencies  must  function  together  supported 
by  a  federation  of  executable  architectures  to  accomplish  a 
common  mission. 

-  Identify  challenges  associated  with  building  a  multi-agency 
Operations-Centric  Architecture  by  combining  architectures 
developed  in  different  architecture  frameworks  (Static  Phase). 

-  Identify  technical  issues  associated  with  developing  an  executable 
version  of  the  Operations-Centric  Architecture  (Dynamic  Phase). 

•  Use  homeland  security  scenario  in  the  case  study 


MITRE 


i 


Center  for  Enterprise  Modernization 


Technical  Approach  -  Static  Phase 
(1  of  3) 


•  Apply  insights  and  lessons  learned  from  previous  research  on 
Multi-Agency  Enterprise  Architecture  Planning  Framework  & 
Executable  Architecture  Methodology  for  Analysis 

•  Use  a  selected  scenario  -  Coastal  Security 

•  Walk  thru  the  process  of  integrating  architectures  from  each 
participating  agency  to  create  an  Operations-Centric  Architecture 
for  the  selected  scenario 

Build  a  generic  Activity  Model  that  captures  the  main  set  of  activities  for  a 
general  case  of  the  selected  scenario 

Map  appropriate  parts  of  individual  organizational  architectures  to  activities 
in  generic  Activity  Model 

-  Conduct  Gap  Analysis  to  identify  which  parts  of  the  mission-oriented 
architecture  are  missing  (i.e.,  individual  organizational  architectures  do  not 
fill  gaps) 

Conduct  Overlap  Analysis  to  identify  where  parts  of  each  individual 
organizational  architectures  describe  same  activities  or  processes 
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Generic  Activity  Model  Construct  for 
Operations-Centric  Architecture 


Mission 


"\  r 


Mission  Essential 
Task  2 


Mission  Essential 
Task  3 


Mission  Essential 
Task  4 
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Extending  the  Generic  Activity  Model 
to  include  Agency-specific  Activities 
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Activity  Model  for 
Coastal  Security  Mission 


CONUS  -  Continental  United  States 
SITREP  -  Situation  Report 
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Static  Phase 

Conduct  Gap  and  Overlap  Analysis 


•  Gaps  -  Activity  is  missing  or  no  Agency  is  performing  a 
Listed  Activity 

-  Hole  must  be  filled  to  achieve  mission  success 

-  Resolve  gap  while  still  in  planning  stage 

-  Can  an  available  Agency  fill  the  gap? 

-  Is  a  new  Agency  needed  to  fill  the  gap? 

-  Make  changes  to  Agency’s  architecture  to  reflect  new  Activity 

•  Overlap  -  More  than  one  Agency  performing  Activity 

-  Is  it  necessary  for  these  Agencies  to  conduct  same  Activity? 

-  Are  different  procedures  being  used  to  perform  Activity? 

-  Will  differences  in  Agency  procedures  create  problems? 
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Technical  Approach  -  Dynamic  Phase 
(2  of  3) 


•  Model  scenario  in  operational  environment  simulation  -  i.e., 
scenario  driver  (JMACE). 

-  Import  maps 

-  Import  entity  icons 

-  Develop  routes  for  key  entities  (vessels,  aircraft,  vehicles,  people) 

Develop  actions  for  key  entities  (detection,  interdiction,  apprehension, . . .) 

•  Import  key  business  processes  from  operations-oriented 
architecture  into  process  modeling  tool  (Bonapart). 

•  Develop  model  of  communications  networks  in  network 
modeling  tool  (NS-2). 

•  Complete  and  test  federation  of  simulations. 

Identify  interactions  between  scenario  driver  and  process  modeling  tools. 


JMACE  -  Joint  Military  Art  of  Command  Environment 
NS-2  -  Network  Simulator  2 
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Joint  Military  Art  of  Command 
Environment  (JMACE) 


•  Developed  by  the  National  Simulation  Center  (NSC)  as  a 
requirements  prototyping  tool  that  identifies  and  defines 
new  approaches  and  requirements  for: 

-  Training  and  exercise  simulations 

-  Decision  support  tools  in  military  operations 

-  Command  Decision  Modeling 

•  JMACE  is  built  on  Gensym’s  G2  environment.  This 
environment  assists  developers  in  simplifying  complex 
functions  into  easily  understood,  concise  code  that  can  run 
on  multiple  platforms  and  operating  systems. 

•  Used  by  the  NSC  in  2001  and  2002  to  support  US  Army 
Command  and  General  Staff  College,  US  Central  Command 
(Operation  Iraqi  Freedom),  and  US  Joint  Forces  Command. 
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Simple  Business  Process 
Modeled  in  Bonapart 
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Multi-Agency  HLA  Federation 


Sends: 

2  —  Msg  traffic 
2  —  Sender  Node 
2  —  Receiver  Node 
2  —  Msg  parameters 

4  — -  Total  Process  time 


Task  Force 
Business 
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Technical  Approach  -  Dynamic  Phase 
(3  of  3) 


•  Run  federation  in  simulation  mode 

•  Conduct  analysis  of  results 

•  Document  technical  issues  and  lessons  learned  for  both  the 
static  phase  and  dynamic  phase 

-  Improvements  to  Enterprise  Architectures 

❖  Activity  Descriptions,  Task  Lists 

❖  Technical  features  (Services,  Data,  Infrastructure) 

-  Improvements  to  Operational  Plans  and  Scenarios 

-  Development  of  Federated  Simulation  Models 
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Model  Interactions  & 
Sample  Measures  of  Merit 


MOFE  -  Vessel  Interdicted 
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Emerging  Insights  &  Lessons  Learned 
(1  of  2) 


•  Multi-agency  modernization  environment  adds 
significant  complexities 

-  Requires  more  specific  detail  in  Architectures 

-  Requires  more  precise  and  uniform  definitions 

❖  Activities 

❖  Business  and  Decision  Rules 

❖  Business  Services 

❖  Information  Services 

-  Requires  strong  analytical  capabilities 

•  Most  architectures  we  examined  were  not  mature 
enough  to  use  in  operations-centric  architecture 

-  Architecture  product  formats  widely  differ  among  agencies 

-  Among  the  architectures,  activities  had  most  commonality,  but: 

❖  Activities  poorly  defined  or  too  general  to  be  usable 

❖  Activities  related  to  specific  scenario  not  complete 
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Emerging  Insights  &  Lessons  Learned 
(2  of  2) 


•  No  clear  set  of  simulation  tools  to  support  analysis 
using  homeland  security  scenarios 

-  DHS  reviewed  100  simulations  for  training  &  exercises 

-  Must  modify  simulations  from  other  domains  to  support 
homeland  security  analysis 


•  Federated  simulations  are  effective  way  to  provide  dynamic 
analysis  capability 

-  EAMA  approach  offers  potential  method  to  conduct  performance 
analysis  as  addressed  in  OMB-FEA  Performance  Reference  Model 

Allows  testing  of  proposed  operations-centric  architecture  “as  used” 


Supports  coalition  and  individual  agency  strategic  and  operational 
planning 


Facilitates  performance  measurement,  management,  and 
improvement 


DHS  -  Department  of  Homeland  Security 

EAMA  -  Executable  Architecture  Methodology  for  Analysis 

OMB-FEA  -  Office  of  Management  &  Budget  Federal  Enterprise  Architecture 
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Summary 


•  This  work  will  improve  the  utility  of  architectures  across  the  government  by 
allowing  architectures  to  be  examined  in  an  integrated  and  dynamic  mode 

An  approach  to  implementing  the  OMB-FEA  Performance  Reference  Model  in  a  multi¬ 
agency  environment 

•  Architectures  can  be  assessed  for  completeness,  connectivity,  information  flow, 
and  performance  in  support  of  their  operational  environment 

•  Organizations  with  multi-agency  missions  will  be  able  to  identify  any 
shortcomings  in  their  operational  structure  and  processes 

•  Cost  and  performance  factors  (for  enterprise  architectures,  mission 
performance,  operational  procedures,  etc.)  can  be  examined  to  facilitate 
resource  allocation 

•  These  capabilities  will  benefit  agencies  trying  to 

-  Plan  for  multi-agency  missions 

-  Determine  their  investment  strategies  and  justify  their  budgets  and  investments  to 
OMB  and  Congress 
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